home *** CD-ROM | disk | FTP | other *** search
/ Belgian Amiga Club - ADF Collection / BS1 part 60.zip / BS1 part 60 / Gods Utils 16.adf / Who.Docs.pp / Who.Docs
Text File  |  1993-04-18  |  9KB  |  159 lines
  1.  
  2.                               WHO   (what?)
  3.  
  4. This here program WHO is originally by -> GEORGE MUSSER Jr <-, but this
  5. version is substantially enhanced (nearly rewritten) by Paul Kienitz.  It
  6. lists the currently active tasks on your Amiga, giving more useful
  7. information about them than other competing hacks do.  To use it, type "who"
  8. into CLI (there are no command line arguments) or double click the icon. 
  9. It's not really a Workbench program; the icon just makes a big CON window
  10. that it writes its output into as if it were in a CLI window, waiting for
  11. you to press any key before removing the window when finished.
  12.  
  13. BEFORE READING FURTHER, try the program.  If you understand the output, you
  14. have little need to read the rest of this.
  15.  
  16. What you see when you run it is a list of tasks (or processes), with one line
  17. of information about each.  First come all the processes that are waiting for
  18. some signal (or message) before continuing, then come those that are
  19. currently ready to run (sharing time slices or waiting for something with
  20. higher priority to get out of the way), and last some information about the
  21. WHO process itself, which of course is the only one actually running at the
  22. moment the information was gathered.
  23.  
  24. Each line starts with the type of task, either `task' if it's a simple Exec
  25. task, `Process' if it's an AmigaDOS process (all processes are tasks but not
  26. vice versa), or `CLI nn' (where nn is the CLI task number from 1 to 20) if it
  27. is a CLI process (all CLI's are DOS processes but etc).  If the CLI is
  28. interactive (with prompts) there's a greater-than sign after the number, like
  29. `CLI 3>'; if none, then this is probably a program started with RUN, or the
  30. CLI is currently executing commands from a script file.
  31.  
  32. The next item is `ID xxxxxx' where xxxxxx is the six-digit hexadecimal
  33. address (I hope that doesn't mess up those with 68020's) of its task control
  34. block (struct Task, or struct Process which is an extended version of that). 
  35. Sometimes AmigaDOS refers to a "process ID" which is the address of a
  36. process's message port.  This is always equal to the task control block
  37. address plus 92 bytes (5C hex).
  38.  
  39. Next is the priority of the task, from -128 to 127, given as `pri nnn'.  Zero
  40. is the typical priority for most user programs.
  41.  
  42. Then comes the task's name, which is a string in quotes, such as "Workbench"
  43. or "File System".  In the case of a CLI process, this name is replaced with
  44. the name of the program currently being run within the CLI, because the name
  45. of the CLI itself is usually uninformative.  In this case, you see something
  46. like `cmd. "utilities/palette"' instead of `name "Palette"'.  Or, you'll see
  47. `(no command)' in the case of a CLI that is prompting for a command to run.
  48.  
  49. This might be the end of the information about the task.  But there are some
  50. optional things that might come next:
  51.  
  52. If the CLI is executing commands from a script file that had a .key
  53. directive in it, it will say something like `script "T:Command-00-T03"',
  54. where the name in quotes is the temporary file that commands are being read
  55. from.  You could, for instance, type out this file to see what commands
  56. resulted from argument substitution.  Unfortunately, if it's reading
  57. commands directly from a simple script file, WHO can't find that file's name.
  58.  
  59. If the task is a "trackdisk.device" driver task, it will then have `unit n',
  60. where n is from 0 to 3, to tell you which floppy drive from DF0: to DF3: this
  61. driver is attached to.  Sorry, I couldn't give unit numbers for any other
  62. devices, because the method of discovering it varies with each device.
  63.  
  64. If this is a DOS handler process, it will say `for NAME:' to tell what DOS
  65. device it is handling, e.g. `name "File System" for DF1:'.
  66.  
  67. If this is a handler process (usually a CON: process) which is handling the
  68. standard output of another process, it will say `for CLI nn' or `for ID
  69. xxxxxx' to identify what other process(es) are sending their standard output
  70. here.  It will say `for this output' for the process that is handling the
  71. output of WHO itself (usually the CON for either the current CLI window or
  72. the window created when you double click the WHO icon).  Multiple for's are
  73. separated by `&', e.g. `name "RAM" for RAM: & CLI 3' (in this case CLI 3 has
  74. it's standard output redirected to a ram disk file).
  75.  
  76. In rare cases, it will say `NODE TYPE nnn' after a task.  Each task normally
  77. contains a node type number which identifies it as being a task (value 1) or
  78. a process (value 13).  If the value is something else, Who will report it. 
  79. It will assume that it's a simple task, not a process, in such cases.
  80.  
  81. Output is sorted as follows: first tasks and then processes; within that, by
  82. decreasing priority (the lower priority ones are probably the ones that
  83. are of more interest), then alphabetically by name.  If it puts out too much
  84. to fit in the window, you'll just have to press the space bar in the middle
  85. to make it wait for backspace, if you want to see the earlier entries.
  86.  
  87. ------------------------------------------
  88.  
  89. If you care, here are what some of the typical mysterious entities you see in
  90. its output are:
  91.  
  92. Non-CLI process named "CLI":  if you double click the icon named CLI or
  93. Shell, it runs a process that creates a CON window and a CLI process, and
  94. then sits around waiting for the CLI to finish so it can close the window.  A
  95. bit inefficient.  My CLImax program works the same way (but I'm going to
  96. improve it someday), so you'll see a process called "CLImax" which is
  97. distinct from the full-screen CLI itself.
  98.  
  99. "File System" process:  This is the DOS handler for a floppy disk drive; it
  100. translates things like "open file foo/bar/ralph" and "read the next 200
  101. bytes" into IO requests like "read track 41 sector 5".  There is one for each
  102. drive in use; they are all the same program.
  103.  
  104. Things like "RAM" for RAM: or "PRT" for PRT: are other DOS handler
  105. processes; in some cases (e.g. RAD:) they are the same as "File System".  In
  106. the case of a hard disk, it might be the Fast File System.  For non-disks, it
  107. might be something like the Port-Handler.
  108.  
  109. "trackdisk.device" task:  the trackdisk device for a given drive receives IO
  110. requests from the corresponding handler process and takes care of managing
  111. the particular hardware of the disk.  Simple devices like timer.device or
  112. keyboard.device don't need separate tasks;  they're just like shared
  113. libraries.  But complex devices like disks need to delegate difficult stuff
  114. to separate tasks, which usually have the same name as the device itself.  If
  115. you have a hard disk, there's probably some task like "scsi.device"; if it is
  116. SCSI there is probably only one task even if there are several disks.
  117.  
  118. "printer.device" task:  this translates generic printer control codes into
  119. the specific control sequences used by your brand of printer, which then get
  120. sent to parallel.device or serial.device, depending.
  121.  
  122. "input.device" task:  this is the source of "input events"; it merges
  123. together input from the keyboard and mouse and feeds the resulting stream to
  124. the back end of Intuition (which sends messages to the programs that use its
  125. front end) and to console.device.  Also any "hot key" programs.  I think. 
  126. I might be a bit confused about this.  Is the back end of Intuition just a
  127. big event handler?  Why would input.device need a separate task and
  128. Intuition not?  Is the input.device task what figures out, like, what gadget
  129. the mouse is over and what menu item was picked?
  130.  
  131. "CON" process:  handles DOS I/O with pseudo-terminal text windows (the
  132. actual terminal emulation is done by console.device, I think.)  Each text
  133. window gets its own handler process.  ConMan works by replacing the program
  134. used by these handlers.  NEWCON is another replacement; I call it "ConBoy".
  135.  
  136. "Workbench" is a program like any other, not something built into the system.  
  137. This distinguishes it from CLI, which isn't a separate program, but some-
  138. thing that gets pieced together by other programs like NewCLI and RUN.
  139.  
  140. ----------------------------------------
  141.  
  142. Differences between my Who and the original George Musser Who:
  143.  
  144. His was much larger (he used Lattice instead of Manx) and couldn't be run at
  145. all from Workbench, and needed an expanded stack to avoid crashing, and
  146. could only list a limited number of tasks.  Also it Disable()d for a longer
  147. interval.  The output did not include:  CLI task number, CLI command name or
  148. script file or interactive flag, any "for" information for handlers, or
  149. trackdisk unit numbers.  The output was not sorted and not aligned in
  150. columns.
  151.  
  152. If you're waiting for me to improve George Musser's other program, KILL
  153. (which could certainly stand some help), don't hold your breath.  Maybe
  154. someday I'll try for a fancy Intuitionized Who/Kill which will hot-key into
  155. existence at priority 127 to save the system.
  156.  
  157. (°¿°) <- Official Seal of Dorkiness certifies that Who was enhanced without
  158. the use of ROM Kernel Manuals.
  159.